Detecting and thwarting spear phishing attacks in electronic messages

ABSTRACT

A computer-implemented method may comprise receiving an electronic message from a purported known sender; accessing a database of known senders and determining whether the sender matches one of the known senders. The degree of similarity of the sender to at least one of the known senders may then be quantified. The received message may then be determined to be legitimate when the purported known sender is determined to match one of the known senders. The received electronic message may be flagged as being suspect when the purported known sender does not match one of the plurality of known senders and the quantified degree of similarity of the purported known sender to one of the known senders is greater than a threshold value. A perceptible cue may then be generated when the received message has been flagged as being suspect, to alert the recipient that the flagged message is likely illegitimate.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related in subject matter to commonly-ownedand co-pending U.S. patent application Ser. No. 14/542,939 filed on Nov.17, 2014 entitled “Methods and Systems for Phishing Detection”, which isincorporated herein by reference in its entirety.

BACKGROUND

A spear phishing email is an email that appears to be from a knownperson or entity. But it is not. The spear phisher often knows therecipient victim's name, address, job title and professional network.The spear phisher knows a lot about his intended victim, thanks to thequantity and rich variety of information available publicly throughonline sources, the media and social networks.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a table showing examples of legitimate email address andspoofed email addresses.

FIG. 2 is a table showing legitimate email address, spoofed emailaddresses and a calculated string metric (e.g., a Levenshtein distance)between the two, according to one embodiment.

FIG. 3 is a flow chart of a method according to one embodiment.

FIG. 4 is a system configured according to one embodiment.

FIG. 5 is a block diagram of a computing device configured according toone embodiment.

DETAILED DESCRIPTION

Spear phishing is a growing threat. Spear phishing is, however, verydifferent from a phishing attack. The differences between a phishingattack and a spear phishing attack may include the following:

-   -   The target of a spear phishing attack is usually a member of the        corporate market, and especially people who have access to        sensitive resources of the company. Typical targets are        accountants, lawyers and top management executives. In contrast,        phishing attacks tend to target all end users more        indiscriminately.    -   Most often, a spear phishing attack is initiated only after a        thorough analysis of the target victim. This analysis is aided        by the great amount of personal and professional information        available on social networks (including, for example, Facebook,        Twitter, LinkedIn and the like), company website and other        media. Consequently, a spear phishing attack is often crafted to        be unique to the targeted individual. Phishing attacks, on the        other hand, tend to be somewhat more indiscriminate, typically        targeting thousands of people.    -   In the first phase of a spear phishing attack, the email        purports to originate from a well-known (to the targeted victim)        and trusted individual, such as a coworker. In contrast,        phishing emails typically appear to originate from a trusted        company (PayPal, Dropbox, Apple, Google, etc.).    -   The second phase of spear phishing attack has a different modus        operandi: a malicious attachment or a malicious Uniform Resource        Locator (URL) that leads the victim to install malware that will        perform malicious operations (e.g., theft of data).        Alternatively, the spear phishing email may contain text in the        body of the email that induces or dupes the victim to perform a        predetermined action (e.g., send a wire transfer, disclose        sensitive information or the like). Instead, phishing attacks        typically rely on the inclusion of a malicious URL only.

According to one embodiment, to protect a user from a spear phishingattack, a protection layer may be applied for each phase of the spearphishing attack. That is, during the first phase of the spear phishingattach, one embodiment detects whether an impersonation of a knownsender is likely. During the second phase of the spear phishing attack,a detection procedure may be carried out, to determine whether thesuspicious email may contain a malicious attachment, a malicious URL orcontains suspect text in the body of the email.

According to one embodiment, to detect whether an email constitutes apotential spear phishing attack, the “From” email address (the sender'semail address) may be scrutinized to detect whether the sender is alegitimate, known and trusted entity or is potentially an impersonationof the same. According to one embodiment, if a user receives an emailfrom an unknown recipient, a check may be carried out to determine ifthe sender's email address is a known contact of the email recipient. Ifthe sender's email address looks like but is in any way different from aknown contact of the recipient, the email recipient may be warned(through the generation of a visual and/or audio cue, for example) thatthe email is at least potentially illegitimate, as impersonating a knowncontact—the essence of a spear phishing attack.

One embodiment is configured to protect the user (e.g., an emailrecipient) by carrying out activities including:

-   -   1. Managing, for the protected user, a list of his or known        email contacts called KNOWN_CONTACTS;    -   2. Managing, for the protected user, a list of blacklisted email        contacts called BLACKLIST;    -   3. Checking each incoming email to determine whether the sender        email address looks like the email address of a known email        contact; and    -   4. Warning the end user if an incoming email is determined to be        potentially illegitimate.

FIG. 1 is a table showing examples of legitimate email address andspoofed email addresses, to email address impersonation. As shown, thelegitimate email address is john.smith@gmail.com. In the first row, thelegitimate joh.smith@gmail.com has been spoofed by replacing the domain“gmail.com” with “mail.com”. In the second row, “gmail.com” has beenreplaced with another legitimate domain; namely, “yahoo.com”. Indeed,the user may not remember whether John Smith's email is with gmail.com,mail.com or yahoo.com, and may lead the user to believe that the emailis genuine when, in fact, it is not. In the third row, the periodbetween “john” and “smith” has been replaced by an underscore which mayappear, to the user, to be a wholly legitimate email address. The fourthrow shows another variation, in which the period between “john” and“smith” has been removed, which change may not be immediately apparentto the user, who may open the email believing it originated from atrusted source (in this case, john.smith@gmail.com). In the fifth row,an extra “t” has been added to “smith” such that the email address isjohn.smitth@gmail.com, which small change may not be noticed by theuser. Lastly, the sixth row exploits the fact that some letters looksimilar, such as a “t” and an “l”, which allows an illegitimate emailaddress of johnsmilh@gmail.com to appear legitimate to the casual eye.

Managing List of Known Email Contacts

According to one embodiment, a list of his known email contacts calledKNOWN CONTACTS may be created and maintained. All email addresses inthis list may be stored in lowercase. According to one embodiment, theKNOWN_CONTACTS list may be initially seeded by the protected user'saddress book. According to one embodiment, the protected user's addressbook, for performance and accuracy reasons, may not be used if itexceeds a predetermined (say 1,000, for example) maximum number ofentries. This predetermined maximum number of entries may be representedby an ADDRESS_BOOK_MAX_SIZE variable (whose default value may be set a1,000). Very large address books may, for example, be associated withvery large companies that share the whole company address book with allemployees.

Another source of legitimate email address to populate theKNOWN_CONTACTS list are email addresses of emails received by the enduser, with the exception of automated emails such as email alerts,newsletters, advertisements or any email that has been sent by anautomated process. The email addresses of people to whom the end userhas sent an email is also another source of legitimate email addresses.According to one embodiment, KNOWN_CONTACTS may be updated in one ormore of the following cases:

-   -   When the address book is updated;    -   When the protected user receives an email from a non-suspect new        contact, with the exception of automated emails such as email        alerts, newsletters, advertisements or any email that has been        sent by an automated process; and/or    -   When the end user sends an email to a new contact.

Managing List of Blacklisted Contacts

According to one embodiment, a list of blacklisted email contacts calledBLACKLIST may also be established and managed. All email addresses inthis list are stored as lowercase. According to one embodiment, if anemail is sent by a sender whose email address belongs to BLACKLIST, thenthat email will be dropped and will not be delivered to the protecteduser.

Detecting a Potentially Suspect or Illegitimate Email Address

When a protected user receives an email, a check may be carried out todetermine whether the sender's email address is known. TheKNOWN_CONTACTS list may be consulted for this purpose. If the emailaddress is not known (e.g., is not present in the KNOWN_CONTACTS list),a determination may be carried out, according to one embodiment, todetermine whether the email address looks like or is otherwise similarto a known address. An email address is made up of a local part, the @symbol and a domain part:

-   -   The local part is the left side of the email address, before the        @ symbol. For example, john.smith is the local part of        john.smith@gmail.com.    -   The domain is the right side of the email address, after the @        symbol. For example, gmail.com is the domain of        john.smith@gmail.com.

According to one embodiment, an email may be considered to be suspect orpotentially illegitimate if both of the following conditions are met:

-   -   The email address is not in KNOWN_CONTACTS, and    -   The local part of the email address is equal or close to the        local part of an email address of KNOWN_CONTACTS.

According to one embodiment, a detection process may be carried out todetermine whether the local part of the received email address has beenspoofed, to appear to resemble the local part of an email address in theKNOWN_CONTACTS list. According to one embodiment, such a detectionprocess may utilize a string metric to compare the local part of anemail address in the KNOWN_CONTACTS with the local part of the receivedemail address. A string metric (also known as a string similarity metricor string distance function) is a metric that measures distance(“inverse similarity”) between two text strings for approximate stringmatching or comparison and in fuzzy string searching. A string metricmay provide a number that is an indication of the distance or similaritybetween two (e.g., alpha or alphanumeric) strings.

One embodiment utilizes the Levenshtein Distance (also known as EditDistance). The Levenshtein Distance operates between two input strings,and returns a number equivalent to the number of substitutions anddeletions needed in order to transform one input string (e.g., the localpart of the received email address) into another (e.g., the local partof an email address in the KNOWN_CONTACTS list). One embodiment,therefore, computes a string metric such as the Levenshtein distance todetect if there has been a likely spoofing of the local part of thereceived email address. The Levenshtein distance between two sequencesof characters is the minimum number of single-character edits (i.e.insertions, deletions or substitutions) required to change one sequenceof characters into the other. Other string metrics that may be used inthis context include, for example, the Damerau-Levenshtein distance.Others may be used to good benefit as well.

FIG. 2 is a table showing a legitimate email address, a spoofed emailaddresses and a calculated string metric (e.g., a Levenshtein distance)between the two, according to one embodiment. In the first row of thetable of FIG. 2, the Levenshtein Distance between the legitimate emailaddress and the address in the Spoofed email address column is zero,meaning that they are the same and that no insertions, deletions orsubstitutions have been made to the local part. In the second row, thespoofed email addresses' domain is yahoo.com, whereas the legitimateaddress' domain is gmail.com. The spoofed email address, therefore,would not be present in the KNOWN_CONTACTS, even though the LevenshteinDistance between the local part of the legitimate email and the localpart of the spoofed email is zero, meaning that they are identical. Asboth conditions are met (the email address is not in KNOWN_CONTACTS andthe local part of the email address is equal or close to the local partof an email address of KNOWN_CONTACTS), the receivedjohn.smith@yahoo.com email would be considered to be suspect or at leastlikely illegitimate. The third row of the table in FIG. 2 shows that theLevenshtein Distance between the legitimate email address and thespoofed email address is 1. In this case, the difference between the twolocal parts of the legitimate and spoofed email addresses is a singlesubstitution of an underscore for a period. Similarly, the fourth row ofthe table in FIG. 2 shows that the Levenshtein Distance between thelegitimate email address and the spoofed email address is 1. In thiscase, the difference between the two local parts of the legitimate andspoofed email addresses is a single deletion of period in the local partof the received email address. The fifth row of the table in FIG. 2shows that the Levenshtein Distance between the legitimate email addressand the spoofed email address is 1 as well. In this case, however, thedifference between the two local parts of the legitimate and spoofedemail addresses is a single insertion of an extra letter “t” in thelocal part. Lastly, the sixth row of the table in FIG. 2 shows that theLevenshtein Distance between the legitimate email address and thespoofed email address is 2. Indeed, the difference between the two localparts of the legitimate and spoofed email addresses is a singleinsertion and a single deletion, as the period has been deleted and an“1” has been substitute for the “t” in the local part.

According to one embodiment, an email address is considered as suspectif the string metric (the Levenshtein Distance in one implementation) dbetween the local part of the email address and the local part of anemail address of KNOWN_CONTACTS is such that

d≦STRING_METRIC_DISTANCE_THRESHOLD

One implementation may include the following functionality:

input : •  address : address to test. lowercase string.•  known_contacts : list of known contacts. Each contact is a lowercasestring. output : •  true if suspect, false otherwise # these parameterscan be configured according to the operational conditions and securitypolicy levenshtein_distance_threshold = 2 localpart_min_length = 6 # ifthe localpart is too short, it is not relevant ifaddress.localpart.length < localpart_min_length :   return false # ifthe address is already known, it is not suspect if address inknown_contacts :   return false # otherwise we check each contact ofknown contacts for each known_contact in known_contacts:  d     =    levenshtein_distance(address.localbart,known_contact.localpart)   if d >=0 and d <=localpart_levenshtein_distance_threshold :    return true # emailaddress is not suspect return false

Above, the minimum length for the local part of the email address hasbeen set at 6 characters and the STRING_METRIC_DISTANCE_THRESHOLD hasbeen set a 2. Of course, other values may be substituted for thesevalues. Indeed, the parameters STRING_METRIC DISTANCE_THRESHOLD andlocalpart_min_length may be readily configured according to operationalconditions and according to the security policies of the deployingorganization.

For example, if the STRING_METRIC_DISTANCE_THRESHOLD is increased, agreater number of spoofing attempts may be detected, but a greaternumber of false positives (email addresses that are legitimate but areflagged as potentially illegitimate) may be generated. A greater numberof false positives may erode the user experience and degrade theconfidence of the protected user in the system and may lead the user todisregard flagged emails.

Flagging an Email as Potentially Illegitimate/Generating Warning Cue

If the email address is suspect, a visual (for example) cue (such as amessage) may be generated to warn the protected user. According to oneembodiment, the protected user may then be called upon to make adecision to:

-   -   confirm that the email address is suspect—the email address is        then added to BLACKLIST and the email is dropped; or    -   deny that the email address is suspect—the email address is then        added to KNOWN_CONTACTS and the email is delivered to the        protected user.

IMPLEMENTATION EXAMPLE

One implementation may include the following functionality:

  function : process_email   input : • email : email received.• known_contacts : list of known contacts. Each contact is a lowercase  string. • blacklist : list of blacklisted contacts. Each contact is a  lowercase string.   output : • true if email has to be dropped, falseotherwise   # extract address from From header [1]   address =email.from_header.address   address = lowercase (address)   # if addressis blacklisted, drop email   if address in blacklist :     return true  # if address is suspicious, warn user   ifis_address_suspicious(address, known_contacts) :     # decision isconfirmed or denied     decision = warn_end_user(address)     ifdecision is confirmed :      blacklist.append(address)      return true    else if decision is denied :      known_contacts.append(address)     return false   # otherwise add address to known_contacts   else :    known_contacts.append(address)     return false

FIG. 3 is a flow chart of a method according to one embodiment. Asshown, block B31 calls for receiving an electronic message (an email,for example) from a purported known sender over a computer network. Inblock B32, a database configured to store a plurality of known sendersof electronic messages (including, for example, the KNOWN_CONTACTS listdiscussed above) may be accessed (either locally or over a LAN or WAN)and it may be determined whether the purported known sender of theelectronic message matches one of the plurality of known senders ofelectronic messages in the database of known senders. As shown at B33,the degree of similarity of the purported known sender of the electronicmessage to one or more one of the plurality of known senders ofelectronic messages stored in the database may be quantified. At B34, itmay be determined whether the purported known sender matches one of theplurality of known senders in the database of known senders. If, so (Yesbranch of B34), the electronic message originates from a legitimatesender, as shown at B35, and the message may be safely delivered to itsintended recipient. If the purported known sender does not match one ofthe plurality of known senders in the database of known senders (Nobranch of B34), it may be determined, as shown at B35, whether thequantified degree of similarity of the purported known sender of theelectronic message to one of the plurality of known senders ofelectronic messages is greater than a threshold value (such as, forexample, the value of the STRING METRIC DISTANCE THRESHOLD variable, asdiscussed above). If no, the electronic message may be legitimate assuggested at B37 or no information may be determined (at least, theelectronic message may be determined to be an unlikely candidate for aspear phishing attack).

As shown at B38, if the purported known sender does not match one of theplurality of known senders in the database of known senders and thequantified degree of similarity of the purported known sender of theelectronic message to one of the plurality of known senders ofelectronic messages is indeed greater than the threshold value, thereceived electronic message may be flagged as being suspect. Thereafter,a visual and/or other perceptible cue, warning message, dialog box andthe like may be generated when the received electronic message has beenflagged as being suspect, to alert the recipient thereof that theflagged electronic message is likely illegitimate.

According to one embodiment, the electronic message may be or maycomprises an email. In Block B33, the quantifying may comprisecalculating a string metric of the difference between the purportedsender and one of the plurality of known senders in the database ofknown senders. In one embodiment, the string metric may comprise aLevenshtein distance between the purported sender and one of theplurality of known senders in the database of known senders.

After block B39, a prompt may be generated, to solicit a decisionconfirming the flagged electronic message as being suspect or a decisiondenying that the flagged electronic message is suspect. Thereafter, theelectronic message flagged as suspect may be dropped when the prompteddecision is to confirm that the flagged electronic message is suspectand the flagged electronic message may be delivered to its intendedrecipient when the prompted decision is to deny that the flaggedelectronic message is suspect.

FIG. 4 is a block diagram of a system configured for phishing detection,according to one embodiment. As shown therein, a spear phishing emailserver or workstation (as spear phishing attacks tend to be somewhatmore artisanal than the comparatively less sophisticated phishingattacks) 402 (not part of the present spear phishing detection system,per se) may be coupled to a network (including, for example, a LAN or aWAN including the Internet), and to a client computing device 412'semail server 408. The email server 408 may be configured to receive theemail on behalf of the client computing device 412 and provide accessthereto. A database 406 of known and trusted senders may also be coupledto the network 404. A Blacklist database 414 may also be coupled to thenetwork 404. A phishing detection engine 410 may be coupled to orincorporated within, the email server 408. Alternatively, some or all ofthe functionality of the spear phishing detection engine 410 may becoupled to or incorporated within the client computing device 412.Alternatively still, the functionality of the spear phishing detectionengine 410 may be distributed across both client computing device 412and the email server 408. According to one embodiment, the spearphishing detection engine may be configured to carry out thefunctionality described herein above and, in particular, with referenceto FIG. 3. The databases 406, 414 may be merged into one database and/ormay be co-located with the email server 408 and/or the spear phishingdetection engine 410.

Any reference to an engine in the present specification refers,generally, to a program (or group of programs) that perform a particularfunction or series of functions that may be related to functionsexecuted by other programs (e.g., the engine may perform a particularfunction in response to another program or may cause another program toexecute its own function). Engines may be implemented in software orhardware as in the context of an appropriate hardware device such as analgorithm embedded in a processor or application-specific integratedcircuit.

FIG. 5 illustrates a block diagram of a computing device such as clientcomputing device 412, email server 408 spear phishing detection engine410 upon and with which embodiments may be implemented. Computing device412, 408, 410 may include a bus 501 or other communication mechanism forcommunicating information, and one or more processors 502 coupled withbus 801 for processing information. Computing device 412, 408, 410 mayfurther comprise a random access memory (RAM) or other dynamic storagedevice 504 (referred to as main memory), coupled to bus 501 for storinginformation and instructions to be executed by processor(s) 502. Mainmemory (tangible and non-transitory) 504 also may be used for storingtemporary variables or other intermediate information during executionof instructions by processor 502. Computing device 412, 408, 410 mayalso may include a read only memory (ROM) and/or other static storagedevice 506 coupled to bus 501 for storing static information andinstructions for processor(s) 502. A data storage device 507, such as amagnetic disk and/or solid state data storage device may be coupled tobus 501 for storing information and instructions—such as would berequired to carry out the functionality shown and disclosed relative toFIG. 3. The computing device 412, 408, 410 may also be coupled via thebus 501 to a display device 521 for displaying information to a computeruser. An alphanumeric input device 522, including alphanumeric and otherkeys, may be coupled to bus 501 for communicating information andcommand selections to processor(s) 502. Another type of user inputdevice is cursor control 523, such as a mouse, a trackball, or cursordirection keys for communicating direction information and commandselections to processor(s) 502 and for controlling cursor movement ondisplay 521. The computing device 412, 408, 410 may be coupled, via acommunication device (e.g., modem, network interface card or NIC) to anetwork 404.

Embodiments of the present invention are related to the use of computingdevice 412, 408, 410 to detect and compute a probability that receivedemail may be or may include a spear phishing attack. According to oneembodiment, the methods and systems described herein may be provided byone or more computing devices 412, 408, 410 in response to processor(s)502 executing sequences of instructions contained in memory 504. Suchinstructions may be read into memory 504 from another computer-readablemedium, such as data storage device 507. Execution of the sequences ofinstructions contained in memory 504 causes processor(s) 502 to performthe steps and have the functionality described herein. In alternativeembodiments, hard-wired circuitry may be used in place of or incombination with software instructions to implement the describedembodiments. Thus, embodiments are not limited to any specificcombination of hardware circuitry and software. Indeed, it should beunderstood by those skilled in the art that any suitable computer systemmay implement the functionality described herein. The computing devicesmay include one or a plurality of microprocessors working to perform thedesired functions. In one embodiment, the instructions executed by themicroprocessor or microprocessors are operable to cause themicroprocessor(s) to perform the steps described herein. Theinstructions may be stored in any computer-readable medium. In oneembodiment, they may be stored on a non-volatile semiconductor memoryexternal to the microprocessor, or integrated with the microprocessor.In another embodiment, the instructions may be stored on a disk and readinto a volatile semiconductor memory before execution by themicroprocessor.

While certain example embodiments have been described, these embodimentshave been presented by way of example only, and are not intended tolimit the scope of the embodiments disclosed herein. Thus, nothing inthe foregoing description is intended to imply that any particularfeature, characteristic, step, module, or block is necessary orindispensable. Indeed, the novel methods and systems described hereinmay be embodied in a variety of other forms; furthermore, variousomissions, substitutions and changes in the form of the methods andsystems described herein may be made without departing from the spiritof the embodiments disclosed herein.

1. A computer-implemented method, comprising: receiving an electronicmessage from a purported known sender over a computer network; accessinga database configured to store a plurality of known senders ofelectronic messages and determining whether the purported known senderof the electronic message matches one of the plurality of known sendersof electronic messages in the database of known senders; quantifying adegree of similarity of the purported known sender of the electronicmessage to at least one of the plurality of known senders of electronicmessages stored in the database; determining the received electronicmessage to be legitimate when the purported known sender is determinedto match one of the plurality of known senders in the database of knownsenders; flagging the received electronic message as being suspect when:the purported known sender does not match one of the plurality of knownsenders in the database of known senders; and the quantified degree ofsimilarity of the purported known sender of the electronic message toone of the plurality of known senders of electronic messages is greaterthan a threshold value; and generating at least a visual cue when thereceived electronic message has been flagged as being suspect, to alerta recipient thereof that the flagged electronic message is likelyillegitimate.
 2. The computer-implemented method of claim 1, wherein theelectronic message comprises an email.
 3. The computer-implementedmethod of claim 1, wherein quantifying comprises calculating a stringmetric of a difference between the purported sender and one of theplurality of known senders in the database of known senders.
 4. Thecomputer-implemented method of claim 1, wherein quantifying comprisescalculating a Levenshtein distance between the purported sender and oneof the plurality of known senders in the database of known senders. 5.The computer-implemented method of claim 1, further comprising promptingfor a decision confirming the flagged electronic message is suspect or adecision denying that the flagged electronic message is suspect.
 6. Thecomputer-implemented method of claim 5, further comprising dropping theflagged electronic message when the prompted decision is to confirm thatthe flagged electronic message is suspect and delivering the flaggedelectronic message when the prompted decision is to deny that theflagged electronic message is suspect.
 7. The computer-implementedmethod of claim 1, wherein accessing also accesses a database ofblacklisted senders of electronic messages and dropping the receivedelectronic message if a sender of the received electronic matches anentry in the database of blacklisted senders of electronic messages. 8.A computing device configured to determine whether a received electronicmessage comprises a spear phishing attack, comprising: at least oneprocessor; at least one data storage device coupled to the at least oneprocessor; a plurality of processes spawned by said at least oneprocessor, the processes including processing logic for: receiving anelectronic message from a purported known sender over a computernetwork; accessing a database configured to store a plurality of knownsenders of electronic messages and determining whether the purportedknown sender of the electronic message matches one of the plurality ofknown senders of electronic messages in the database of known senders;quantifying a degree of similarity of the purported known sender of theelectronic message to at least one of the plurality of known senders ofelectronic messages stored in the database; determining the receivedelectronic message to be legitimate when the purported known sender isdetermined to match one of the plurality of known senders in thedatabase of known senders; flagging the received electronic message asbeing suspect when: the purported known sender does not match one of theplurality of known senders in the database of known senders; and thequantified degree of similarity of the purported known sender of theelectronic message to one of the plurality of known senders ofelectronic messages is greater than a threshold value; and generating atleast a visual cue when the received electronic message has been flaggedas being suspect, to alert a recipient thereof that the flaggedelectronic message is likely illegitimate
 9. The computing device ofclaim 8, wherein the electronic message comprises an email.
 10. Thecomputing device of claim 8, wherein quantifying comprises calculating astring metric of a difference between the purported sender and one ofthe plurality of known senders in the database of known senders.
 11. Thecomputing device of claim 8, wherein quantifying comprises calculating aLevenshtein distance between the purported sender and one of theplurality of known senders in the database of known senders.
 12. Thecomputing device of claim 8, wherein the processes further compriseprocessing logic for prompting for a decision confirming the flaggedelectronic message is suspect or a decision denying that the flaggedelectronic message is suspect.
 13. The computing device of claim 12,wherein the processes further comprise processing logic for dropping theflagged electronic message when the prompted decision is to confirm thatthe flagged electronic message is suspect and for delivering the flaggedelectronic message when the prompted decision is to deny that theflagged electronic message is suspect.
 14. The computing device of claim8, wherein the processes further comprise processing logic for accessinga database of blacklisted senders of electronic messages and droppingthe received electronic message if a sender of the received electronicmatches an entry in the database of blacklisted senders of electronicmessages.
 15. A tangible, non-transitory machine-readable data storagedevice having data stored thereon representing sequences of instructionswhich, when executed by a computing device, cause the computing deviceto: receive an electronic message from a purported known sender over acomputer network; access a database configured to store a plurality ofknown senders of electronic messages and determine whether the purportedknown sender of the electronic message matches one of the plurality ofknown senders of electronic messages in the database of known senders;quantify a degree of similarity of the purported known sender of theelectronic message to at least one of the plurality of known senders ofelectronic messages stored in the database; determine the receivedelectronic message to be legitimate when the purported known sender isdetermined to match one of the plurality of known senders in thedatabase of known senders; flag the received electronic message as beingsuspect when: the purported known sender does not match one of theplurality of known senders in the database of known senders; and thequantified degree of similarity of the purported known sender of theelectronic message to one of the plurality of known senders ofelectronic messages is greater than a threshold value; and generate atleast a visual cue when the received electronic message has been flaggedas being suspect, to alert a recipient thereof that the flaggedelectronic message is likely illegitimate.
 16. The tangible,non-transitory machine-readable data storage device of claim 15, whereinthe electronic message comprises an email.
 17. The tangible,non-transitory machine-readable data storage device of claim 15, whereinquantifying comprises calculating a string metric of a differencebetween the purported sender and one of the plurality of known sendersin the database of known senders.
 18. The tangible, non-transitorymachine-readable data storage device of claim 15, wherein quantifyingcomprises calculating a Levenshtein distance between the purportedsender and one of the plurality of known senders in the database ofknown senders.
 19. The tangible, non-transitory machine-readable datastorage device of claim 15, wherein the stored sequences of instructionsfurther comprise prompting for a decision confirming the flaggedelectronic message is suspect or a decision denying that the flaggedelectronic message is suspect.
 20. The tangible, non-transitorymachine-readable data storage device of claim 15, wherein the storedsequences of instructions further comprise dropping the flaggedelectronic message when the prompted decision is to confirm that theflagged electronic message is suspect and delivering the flaggedelectronic message when the prompted decision is to deny that theflagged electronic message is suspect.
 21. The tangible, non-transitorymachine-readable data storage device of claim 15, wherein the storedsequences of instructions further comprise accessing a database ofblacklisted senders of electronic messages and dropping the receivedelectronic message if a sender of the received electronic matches anentry in the database of blacklisted senders of electronic messages.